Subject: appnNodeLsState and appnNodeLsSubState

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Mon, 18 Sep 95 08:00:56 EDT

At AIW8 we talked about possibly cleaning up these two objects, so
here's a proposal.  Right now we have the following:

1.  appnNodeLsState, with 4 values, playing two roles:

      a.  The switch that lets a Management Station change a link
          station's state.

      b.  An object that shows a Management Station a high-level state
          for a link station.

2.  appnNodeLsSubState, with 15 values, which shows a Management Station
    the exact state of a link station.

How about the following alternative, with three objects?

1.  appnNodeLsAdminState    OBJECT-TYPE
        SYNTAX INTEGER {
                 inactive(1),
                 active(3),
                 ready(5)
                 }
        MAX-ACCESS read-write
        STATUS current
        DESCRIPTION
             "Object by which a Management Station can activate
             or deactivate a link station, by setting the value
             to active(3) or inactive(1), respectively.  The value
             ready(5) has no meaning on a set operation."

        ::= { appnNodeLsEntry xx }

2.  appnNodeLsOperState    OBJECT-TYPE
        SYNTAX INTEGER {
                 inactive(1),
                 pendactive(2)
                 active(3),
                 pendinact(4)
                 }
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
             "Summary of the state of this link station."

        ::= { appnNodeLsEntry yy }

3.  appnNodeLsSubState, essentially with its current definition, although
    we'll want to check the states against the current FSMs to make sure
    that they still reflect the architecture.

Thanks,
Bob